The popularity of the Internet has given rise to e-commerce. As illustrated in FIG. 1, many consumers 102 enjoy the convenience of shopping at home via websites 104 such as Yahoo!, Amazon.com and eBay, as well as on-line banking via websites 104 provided by banks such as Citibank. Many other activities that formerly required live interactions either in person or via phone can be conducted on-line, such as applying for car or health insurance, buying and selling stocks, etc. via the Internet 106.
Such on-line activities typically require the exchange and storage of personal information such as credit card numbers and banking information. Accordingly, consumers want to be able to trust that the websites 104 are secure from on-line vulnerabilities, such as the ability for hackers to gain access to their personal information.
The inventions and technologies described in co-pending U.S. patent application Ser. Nos. 10/113,875 and 10/674,878, the contents of which are incorporated herein by reference, have dramatically advanced the state of the art of vulnerability detection, assessment and management. For example, these co-pending applications describe techniques for performing vulnerability scans of websites, and hosting and controlling the contents of a mark in accordance with the scan results that indicates to visitors of the website how safe the website is. These vulnerability scans aim to duplicate and/or exploit methods known to be used by hackers to attempt to gain unauthorized access to the devices and systems of the website. Nevertheless, areas of potential improvement exist.
Websites such as 104 are accessed by client software programs over the Internet via a protocol known as Hypertext Transfer Protocol (or HTTP). Using an HTTP request, a client can ask for specific content from a website and/or send user data to the website. Per the specification of the request, the website generates content and returns the content to the client via a corresponding HTTP response. A web browser (e.g. Internet Explorer) is the most common example of an HTTP client. Web browsers make HTTP requests when users type in URLs or click on links or submit forms present in the content of the website. In the specific case of submitting a form, information keyed into the form by the user is included with the HTTP request. When generating content for a response, websites often dynamically construct code based on an HTTP request; and the code is executed by a corresponding interpreter. Dynamically constructed SQL statements executed by a relational database are the most common example, but any other language and interpreter including Ruby, PHP, PERL, Python, etc. can serve.
Accordingly, many web applications employ interpreters capable of executing source code from various programming languages. Many of these languages are suited specifically for web application development and support concise programmatic directives for including source code from remote locations. These directives allow common resources to be reused and composed dynamically across a network into more elaborate constructs, eliminating redundancy in the creation of source code and in the deployment of application resources.
The ability to cause a web application to illicitly include an external resource and attempt to execute the resource as part of the application's operation is known as remote file inclusion. This class of vulnerability is potentially severe as the web application can be instructed to execute arbitrary malicious code, such as code from a hacker who wants to disrupt or surreptitiously access the web application.
For example, a web application using the popular PHP programming language might include a line of code that looks like “include $foo;”. A programmer may have errantly allowed the variable “foo” to be assigned with unfiltered data from an HTTP request. A hacker, knowing or suspecting this vulnerability, may send an HTTP request to the web application, and surreptitiously include in the request a directive that re-assigns the variable “foo” to a URL controlled by the hacker and pointing to malicious code. Then, upon the next execution of the given line, the PHP interpreter will attempt to load and execute the resource of the hacker's URL, which could be potentially damaging to the website and/or its users.
Accordingly, there remains a need in the art for a method and apparatus to effectively detect vulnerabilities such as remote file inclusion.